In recent years, communication technology has widely spread in terms of number of users and amount of use of the telecommunication services by the users. This also led to an increase in the number of different technologies and technological concepts in use, which relates both to core network parts and to access network parts of communication systems.
In particular, a trend of convergence in the field of communication systems leads to multi-access environments, in which a plurality of different accesses (i.e. access types, technologies and/or networks) are available. That is, a user (or user equipment) may get attached to a communication system (e.g. to connect to a core or service network) via any one of a plurality of access options available.
A first example for a multi-access environment as currently known is based on the TISPAN (Telecommunication and Internet Converged Services and Protocols for Advanced Networking) approach by ETSI (European Telecommunications Standards Institute). The TISPAN approach provides for inter-operable and inter-domain support of mobility, roaming and multiple services in all-IP (IP: Internet Protocol) networks.
In TISPAN, a centralized element arranged in the core network part is responsible for performing address allocation, AAA functions (AAA: authentication, authorization and accounting), location (mobility) management and access network configuration. This element is usually referred to as network attachment subsystem NASS. The NASS element may also be distributed between a visited network (hereinafter referred to as access domain) and a home network (hereinafter referred to as core or service network).
The main functions and interfaces of a network attachment subsystem (NASS) element as defined in current TISPAN specifications are presented in FIG. 1 of the accompanying drawings. As can be seen in FIG. 1, a user equipment is connected to a NASS element via interface e3, and the NASS element is connected to a core network part of the communication system via interface e2. Furthermore, the NASS element is connected to a resource and admission control subsystem (RACS) via interface e4. As FIG. 1 merely serves as a general overview of TISPAN architecture with respect to a NASS element, and the individual functional blocks depicted are considered to be well-known for a person skilled in the field of mobile communications, a detailed description thereof is omitted herein. Reference is made to the list of abbreviations at the end of this specification.
The main functions of a NASS element may be summarized as follows: dynamic provision of IP (Internet Protocol) address and other user equipment configuration parameters (e.g., using dynamic host configuration protocol DHCP); user authentication, prior or during IP address allocation; user authentication based on a user network profile (for example based on point-to-point protocol PPP, hypertext markup language HTML, wireless communications according to IEEE 802.11X standards, protocol for carrying authentication for network access (PANA) of the Internet Engineering Task Force IETF), line authentication based on layer 2 (of ISO OSI reference model) line identification, location management (e.g. for emergency call, etc.), customer premises equipment (CPE) configuration, and P-CSCF (proxy call session control function) announcement.
In detail, the block level functions of a NASS element are the following. A Network Address Configuration Function (NACF) serves for IP address allocation to CPE, for distribution of other network configuration parameters such as address of DNS (domain name system) server(s), address of signalling proxies for specific protocols (e.g., P-CSCF). The NACF function is typically implemented as RADIUS (Remote Authentication Dial-In User Service) servers or DHCP (Dynamic Host Configuration Protocol) servers. An Access Management Function (AMF) serves for translating network access signalling between CPE and NACF/UAAF and for forwarding requests to the UAAF (User Access Authorization Function) to authenticate the user, authorize/deny network access and retrieve user-specific access configuration parameters. The AMF function is typically implemented as RADIUS client, if the NACF is implemented as RADIUS server. A Connectivity Session Location Repository Function (CLF) serves for registering an association between the IP configuration of the CPE and access transport characteristics, line identifier, IP edge identity, geographical location, etc. Further, it the CLF function serves for providing user network profile information to the RACS and for providing location information to TISPAN network core subsystems. The UAAF serves for performing user authentication and authorisation based on user profiles, and for collecting accounting data. A Profile Database Function (PDBF) serves for storing the user network profile containing user identity, supported authentication methods and keys. The PDBF function may be co-located with the User Profile Server Function (UPSF). A Customer Network Gateway Configuration Function (CNGCF) serves for providing a customer network gateway (CNG) with additional initial configuration information (firewall, DiffServ packet marking, etc.).
A second example for a multi-access environment as currently known is based on an approach of the Third Generation Partnership Project (3GPP). Although no element such as a NASS according to TISPAN exists in the 3GPP approach, there exist similarities, for example that there are needs to authenticate and authorize users to use different types of accesses and services. However, a common functionality for service authorization and policy and session management (such as realized by interfaces e2 and e4 of a TISPAN NASS element) is missing in the 3GPP approach.
Nevertheless, in 3GPP there are AAA servers present in the architecture, which serve for authentication and obtaining user profiles related to a certain service. Just as in the TISPAN approach, these AAA servers performing AAA functions are arranged in a core network part of an underlying communication system.
That is, in both conventional multi-access environments as set out above, there exists a centralized (i.e. core network based) authentication and mobility management functionality.
Hence, access type changes due to user mobility (i.e. roaming) are visible in the home (core) network of the user. Therefore, the home network (e.g. NASS) returns in an initial network authentication all parameters that are required (i.e. keying material, quality-of-service parameters) for network attachment for all supported access types.
When the access type changes are visible to the home network such as in known approaches, this leads to following disadvantages. First, there exists a considerable signaling delay e.g. for authentication functions. The signaling delay may prevent handovers to be seamless which is however desired in view of high user mobility. Second, the signaling load at a centralized AAA and mobility management element (e.g. NASS or AAA server) increases heavily causing expensive implementation and possibly processing overload resulting in service degradation or even outage.
In view of the above it is evident that, with current authentication methods, an access domain/type requests a home subscriber system HSS or a home location register HLR to provide authentication vectors each time per access node. Once a user moves out of the area of the current access node, unused authentication vectors are never used.
Taking an example: A user at home uses DSL, in morning goes to the office using 2G/3G access mobility, in office he/she uses WLAN. At the end of the day, he/she goes home using 2G/3G mobility and back home DSL network. This leads to in total four inter-access handovers (i.e. DSL->2G/3G->WLAN->2G/3G->DSL), and hence several authentications in different access domains. Each such authentication causes signaling to the core network part, being liable to delay and load restrictions.
A migration to multi-access domains in future communication systems means that even more access authentication is needed, hence more communication bandwidth would be needed when using current authentication methods and/or architectures.
Accordingly, a solution for multi-access environments is required, which is able to prevent access type changes from being visible in the home (core) network.